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(57) Abstract 



orwaidlng^ha cludes establishing criteria for selecting among possible links between nodes 



A method and system of 

for forwarding calls from an originating node to a destination node. In the preferred embodiment! the selection of the possible links is 
made at a called node from which the call is to be forwarded. Based upon the administrable criteria, there is a determination as to whether 
an intermediate node along the call path between the originating node and the called node is to be selected for initiating the forwarding 
P*** 1 * lf J™ intermediate node is selected, a request is transmitted to the intermediate node to initiate the forwarding path to the destination 
node. On the other hand,Jf_iip,mteT^ ^ a d ft c rmw atioaOs-^na^ 



the originating node or from the called node. Again, the determination is made according to the administrable criteria. Typically, the most 
unportant factor in selecting among the nodes relates to minimizing the link necessary to connect the calling party to the forwarded-to party, 
thereby releasing links for other use within a network. 
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CALL FORWARD MANAGED REROUTING 

TECHNICAL FIELD 

The invention relates generally to methods and systems for 
5 managing call forwarding and more particularly to methods and systems for 
selecting among a number of possible nodes for initiating a forwarding path 
for a call. 

BACKGROUND ART 

10 Systems that allow a call to be forwarded from a called node of 

a network to another node are well known. If a user who receives service via 
a first node enables call forwarding to a user site that is serviced by means of 
a second node, a call to the first node will be diverted to the second node. 
Thus, there is a call path from the originating node to the first node and a 

15 forwarding path from the first node to the second node in order to place a 
calling user in contact with the called user. 

While the c ajljoiwgfgin g^pability provides a number of 
conveniences, the prior art approach is susceptible to adding significantly to 
the costs of certain types of call connections. For example, a call may be IT 

20 originated from a node within the United States, while the called node may be 
in Germany. This call path will typically require the use of relatively expensive 
international integrated services digital network (ISDN) facilities, either 
switched or leased. If the destination node to which the call is to be diverted 
is also within the United States, an international trunk will again be required 

25 for the forwarding path from the called node to the destination node. The 
double use of the international trunk will significantly increase the cost of the 
connection call from the originating user to the destination user. 

U.S. Pat No. 5,452,349 to Uehara et al. describes an 
improvement for use in a communication system that includes a public 

30 network connected to an ISDN. A call deflection control system is included 

_ _ within4he-publiG-networi^ — — 

public network, a judgment will take place upon receiving a call from a 
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terminal of the ISDN. The control system judges whether the call is to be for- 
warded to a terminal of the called public network or to a terminal of the 
originating ISDN. If the call is to remain within the public network, the 
forwarding is executed at the terminal of the public network. On the other 
5 hand, if the call is to be forwarded to a second terminal of the ISDN, a request 
is made to the ISDN to execute call forwarding. This eliminates the problems 
associated with using two different ISDN lines. 

The system of Uehara et al. has advantages over prior art call 
forwarding control systems. However, application of the system is limited, 
10 For example, the destination of the forwarded call may be in a third network, 
so that the Uehara et al. system is not applicable. 

What is needed is a method and system for managing calls to 
be forwarded such that facilities and resources are conserved. 

15 SUMMARY OF THE INVENTION 

A method and system of managing the forwarding of calls 
includes determining which of an originating node, a called node or an 
intermediate node is the optimal node for initiating a link to a location to which 
the call is to be forwarded, i.e., the destination node. The determination of 

20 the appropriate node for initiating a forwarding path to the destination node is 
based upon administrabie predefined criteria which allow a party to customize 
the call forwarding operation to meet specific network requirements of the 
party. In the preferred embodiment, the criteria include the originating user's 
permission to be forwarded, the location and the connectabiiity of the 

25 destination node relative to each of the originating node, the called node, and 
any tandem/gateway nodes that may be intermediate along the call path from 
the originating node to the called node. 

The first step in the method of managin&c in^ 
establish criteria for selecting among alternative forwarding paths for reaching 

30 the destination node to which the call is allowed to be forwarded when the 
forwarded-to user is remote from the forwarding user. Typically, the 



established criteria have a goal of minimizing links that are used to establish 
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the connection. This provides a savings in terms of costly trunk facilities and 
lowers the traffic load, particularly when a network includes international links. 
However, other factors are relevant. For example, a node may not have the 
capability of initiating a forwarding path, so that there must be a provision for 
5 determining forwarding capability. Another possible factor in the selection of 
a node for initiating a forwarding path relates to traffic along a particular link at 
the time of forwarding a call. If a link of a potential forwarding path is 
detected to be particularly busy, that link may be disregarded in the selection 
of a path. 

10 I" the preferred embodiment, the next step is to determine 

whether an intermediate node along the call path from the originating node to 
the called node is to be selected for initiating the forwarding path to the 
destination node. Conventionally, nodes are grouped according to certain 
attributes, such as geographical proximity, network protocol type, and routing 

15 and rerouting attributes. A "node group" is also referred to herein as a 

"logical boundary." Links between some node groups may be simple private 
network links, while connections between node groups having incompatible 
attributes may require one or more gateway nodes and an expensive gateway 
link in order to allow communication between the nodes of the different 

20 groups. The gateway node from one network to another network is typically 
also a major hub within the network in which the gateway node resides. The 
links between nodes or node groups may be public switched ISDN links or 
private ISDN links. The end-user or end-nodes may be non-ISDN links. An 
intermediate .node that performs the call forwarding rerouting acts on behalf of 

25 the end-user. 

If in the implementation of the method it is determined that an 
intermediate node is to initiate the forwarding path, a request is transmitted in 
the backward direction from the called node. This request specifies the 
identification of the intermediate node which is to establish the-eairTorwardingT""^ 
30 In the preferred embodiment, the intermediate node is alonVthe"caIi path 
from the originating node to the called node, so that the intermediate node is 
in a position to save information within the setup message as it is originally 
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transmitted from the originating node to the called node. For example, the 
identification of the originating node is saved and the identification of the 
forwarding node is added to the setup information when the intermediate 
node is requested to perform the redirection. While not critical, the 
5 saving/appending of information by the intermediate node may require that 
the call forwarding capability be set "active" at the intermediate node. 

Upon determining that an intermediate node is to be used to 
initiate the call forwarding path, the request is transmitted from the called 
node to the intermediate node. The link between the called node and the 

10 intermediate node is then disconnected, freeing this link for other calls. 

If there is no intermediate node or if no intermediate node is 
selected for initiating the forwarding path, the established criteria are utilized 
to select between initiating the forwarding path from the originating node or 
from the called node. In most instances, if the destination node is in the same 

15 group as the called node, the call is diverted from the called node, using 
techniques well known in the art. If the destination node is within the same 
group as the originating node, the originating node is typically the selected 
node for initiating the forwarding path. However, the established criteria may 
dictate a different arrangement, such as for instances in which the originating 

20 node does not support call forwarding service. 

If the originating node is to be used to initiate the forwarding 
path to the destination node, the call path to the called node can then be 
disconnected. Again, there is a savings of processing and link resources. 
Managed call forwarding translates into potential savings in cost and 

25 significant increases in link availability. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a schematic representation of an exemplary topology in 
accordance with the prior art. 
30 Fig. 2 is a flow chart of steps for establishing conditions for call 

forwarding in accordance with the invention. 

Fig. 3 is an exemplary control table formed in one of the steps of 
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Fig. 2. 

Fig. 4 is a flow chart of steps to be followed in managing a 
particular call to be forwarded in accordance with the invention. 

Fig. 5 is a table of alternative events to be implemented upon 
5 encountering step 68 of Fig. 4. 

Figs. 6A and 6B are a flow chart of steps to be followed in 
performing the forwarding at an intermediate node in accordance with the 
invention. 

Fig. 7 is an exemplary topography that may be encountered in 
10 implementing the steps of Fig. 4. 

Figs. 8 and 9 are illustrations of connections and messages in 
which a gateway node is selected to initiate call forwarding. 

Fig. 10 is a block diagram of major components of call 
forwarding management rerouting in accordance with the invention. 
15 Figs. 11 and 12 are illustrations of message flow in call 

forwarding by means of an intermediate node that is not a gateway node. 

PEST MODF FOR CARRY ING OUT THE INVENTION 

With reference to Fig. 1 , an example of a network topology is 

20 shown as including three interconnected networks 10, 12 and 14. Each " 
network includes more than one group of nodes. Each group is referred to 
herein as a "logical boundary" (LB). Logical boundaries may be based upon 
routing attributes and/or on geographical location. Each network includes a 
number of logical boundaries. The assignment of a logical boundary to a 

25 particular network is based upon geographical location and the network 
protocol type. 

Within the first network 10 are three logical boundaries 16, 18 
and 20. Communication between two nodes within the same logical 
boundary or between two nodes of different logical boundaries, but within the 
30 same network, may take place by private network links. The private network 

links are represented by the thinner node-connection lines in Fio. 1. O nthe 

other hand, connections between nodes of different networks 10, 12 and 14 
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may take place by means of gateway links 22, 24 and 26, as represented by 
the thicker node-connection lines. Each gateway link is connected to at least 
one gateway node 28, 30, 32 and 34. The gateway nodes are more powerful 
nodes that support the gateway links, which are typically expensive 
5 international ISDN facilities, either switched or leased. Often, each gateway 
node is also a major hub within the network in which the node resides. 

Following most prior art techniques, the call forwarding 
procedure is one in which a call path is formed from an originating node to a 
called node and then a forwarding path is formed from the called node to the 

10 designated destination node. This is known as "forward switching" at the 
called/redirecting node. For example, if a user who is served by one of the 
Los Angeles nodes of logical boundary 16 calls a user who is served by 
gateway node 34 in the Helsinki logical boundary 36, the call path will be from 
the node of LB2 to the node of LB5. If the called user has designated a node 

15 in the New York logical boundary 1 8 for purposes of call forwarding, the 
forwarding path will be from LBS to the designated node of LB1 . This 
connection of the calling party to the forwarding party requires two uses of an 
expensive international trunk of the gateway link 22. 

In contrast to prior art techniques, the invention manages call 

20 forwarding by selecting among a number of possible nodes for initiating a 
forwarding path to the designated destination node. In the preferred 
embodiment the first step is a selection process based on a "control" table 
which is used to determine whether an intermediate node along the call path 
from LB2 to LBS is to be selected as the node from which a forwarding path is 

25 to be initiated. As will be explained in greater detail below, if gateway node 
28 is selected, the called node of LBS will then transmit a forwarding request 
to the gateway node 28. When the forwarding path is formed, the link 
between the node of LBS and the gateway node can be released. 

Still referring to the preferred embodiment, if an intermediate 

30 node along the call path is not selected, there is a determination as to 

whether the called node or the originating node should initiate the forwarding 
path, based again upon the "control" table: For the example in which the 
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originating node is in the same network 10 as the destination node, the 
originating node is more likely to be selected. However, the criteria for 
selecting among nodes must include the determination of whether a particular 
node supports call forwarding. If the originating node of LB2 does not include 
5 call forwarding capability, the called node will be selected to initiate the 
forwarding path. If an originating node is selected, a forwarding request is 
transmitted to the originating node and the link between the originating node 
and the called node can be released. 

The call forward managed rerouting system may be a 

1 0 supplementary service for private telecommunication networks/exchanges 
(PTN/Xs), where rerouting may be via private links or a virtual private network 
using switched public network links. Upon encountering a called user who is 
forwarding to a remote location, the system ideally provides the most 
economic rerouting path, as predefined by administration. The rerouting may 

1 5 be performed by the originating node, the called node, or a specified 
intermediate node. 

Call forward managed rerouting (CFMR) includes at least two 
services, CFMR at the served user switch (CFMR_S) and CFMR at the 
rerouting switch (CFMR_R). 
20 Referring now to Fig. 2, each node (PTN/X) in the networks ; 10, 

12 and 14 of the type shown in Fig. 1 is assigned a unique node identification. 
The assignment is shown as step 38. Each node is aware of its assigned 
network-wide unique node ID, so that the node ID may be transmitted with the 
conventional setup information whenever a call is placed. The node ID may 
25 be embedded within the numbering plan. 

Step 40 is the function of administering intermediate nodes to 
activate CFMR_R service in order to store the necessary information and 
monitor the D-channel in the backward direction for a call forwarding request. 
Additional detail regarding the CFMR_R service will be set forth immediately 
30 below, when referring to step 43. 

_____ Two >ocal tables are administered in step 42 in order to provide 

information for selecting among possiblenodes for initiating a forwarding 
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path. A "case event" table (Fig. 5) is the action that is to be taken depending 
upon the result from the Rerouting at Forwarding or Originating Node 
Determination Algorithm. A "control" table (Fig. 3) is used to store selection 
data. 

5 In step 43 f services are invoked. CFMR_S is invoked at the 

node of the subscriber that activates call forwarding to a remote site. The 
service is invoked automatically at the called node when an incoming call 
reaches the called site. CFMR_R is provided at the rerouting switch where 
the intermediate node (i.e., tandem/gateway node) CFMR is active on a 
10 per-trunk-group basis. A trunk group may be administered for 

CFMR_R_active or may be administered for CFMR_R_jnactive. This service 
will be automatically invoked at an intermediate node depending upon how 
the relevant trunk group has been administered. If the trunk group is 
administered as inactive, the intermediate node will not save the necessary 
15 data for subsequent rerouting or monitor the D-channel at that intermediate 
node, so that any forwarding request messages will be passed through the 
node for action by a preceding node in the call path. 

Fig. 3 is an illustration of an implementation of a CFMR control 
table 44. A first column 46 identifies an optional incoming trunk group 
20 assignment. For flexibility and alternate routes, more than one trunk group 
can be specified for a node ID/digit string. In a second column 48, the node 
IDs are identified. Each node ID in the network must have a table entry and 
its logical boundary number. Digit strings may also be entered (e.g., full or 
partial public number). It is recommended that the numbering plan region or 
25 location code be used as the node ID of a node, since "it may be necessary to 
correlate the calling party number, the forwarding number and the forwarded- 
to number to the node ID. For example, in the United States, the node ID 
may be the area code plus an office code that is based on the DID number for 
the particular subscriber, e.g. 407997. However, other techniques may be 
30 used in establishing node IDs. 

A third column 50 of the control table 44 identifies the logical 
boundary number. As previously noted, nodes within the same geographical 
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area and/or within the same network are grouped into logical boundaries. 

A home node indication column 52 identifies the node at which 
the control table 44 is stored. As an alternative to providing the column 52, 
the identification of the home node can be derived from some other location 
5 within the local database. 

A transit/gateway node ID column 54 is a field that specifies the 
forwarding node for calls that are to be rerouted from a particular intermediate 
node, such as a gateway node or transit (i.e. "tandem") node. The specified 
intermediate node must be within the call path. That is, the identified node 
1 0 must be one of the nodes used in the setup connection from the originating 
node to the called node. 

The control table 44 of Fig. 3 can be used to store public 
network digit string patterns as the node ID when the client network requires 
incoming calls with a specified digit pattern match to be rerouted at a partic- 
15 ular intermediate node. The control table need not take the configuration ' 
shown in Fig. 3, since other implementations may be used with acceptable 
results. The residency of the information is preferably at the called node. 
Thus, CFMR_S would be resident at every node which has subscribers. 
However, the implementation may be at a gateway, rather than at each node, 
20 i.e., PTN/X. Storing the information at the gateway reduces the complexity of 
administration, but jeopardizes the selection of an optimal forwarding path to 
the destination node. 

As an implementation option, a second CFMR control table can 
be administered to replace the first during specified times of each day or 
25 during specified days of the week. For example, the second control table 
may be utilized during non-peak periods. 

The step 42 of administering the CFMR control table is at least a 
portion in the operation of establishing criteria for selecting among various 
nodes for initiating a forwarding path. Typically, the established criteria have 
30 a goal of minimizing links for connecting the calling party to the forwarded-to 
P art y Th's provides a savings in terms of trunk facilities and lowers the traffic 
load. Other factors may or must also be considered in establishing the 
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criteria. For example, a particular node may not support call forwarding, so 
that the node must be eliminated from the selection of nodes. Another factor 
is traffic along a link. If a link is particularly busy, rt may be preferred to select 
a lengthier, but less busy, forwarding path. 
5 Fig. 4 illustrates a sequence to be followed in the management 

of a particular call that is to be forwarded. In step 56, a determination is made 
as to whether call forwarding has been invoked/ with the forwarding being to 
an address that is remote from the served user, i.e. the called node. A 
determination 57 is also made as to whether call forwarding is authorized by 

1 0 the caller. If either determination results in a "no." no action is taken by the 
call forwarding service. If "yes," the calling party's node ID is determined at 
step 58. The management system may implement this step by performing a 
look-up of the calling party's node ID from a control table 44, such as the one 
shown in Fig. 3. The node ID can be derived from the private calling party's 

1 5 number or obtained from the call setup message from the originating node. 

In step 60 f a determination is made as to whether to select a 
tandem/gateway node for initiating a forwarding path to the destination node. 
Again, the control table 44 plays a role. If the control table specifies a 
gateway node that is to be used for forwarding calls from the node that is 

20 identified in step 58, a request message will be transmitted from the called 
node to the specified gateway node, shown at step 62. The request message 
carries the identification of the gateway node from which call rerouting is to be 
activated. Alternatively, a non-gateway intermediate node along the call path 
may be specified. That is, the specified intermediate node need not be a 

25 gateway node. 

When an administrator specifies an intermediate node ID for call 
rerouting, as set forth in the CFMR control table 44, the specified node should 
be administered for CFMR_R_active for a specified trunk group. If this is not 
done, the forwarding request message will be transparent to the specified 

30 node 

In step 64 t the specified intermediate node initiates the 
forwarding path in response to the request message from the called node. If 
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the intermediate node has been set CFMR_R_active, it will have saved at 
least some of the setup information that was transmitted from the originating 
node to the called node. Consequently, the intermediate node will be aware 
of the node ID of the originating node. 
5 The forwarding request contains the redirecting and redirection 

name and number which are sent in the SETUP message to the destination 
node. The selected intermediate node sequentially performs at least four 
functions. Firstly, acknowledgement is sent to the called node in response to 
the forwarding request. Secondly, the SETUP message to the destination 
1 0 node is prepared to include the saved SETUP information and the redirecting 
and redirection name and number from the forwarding request. (Note: the 
redirecting number ID may include the reason for the^caH forwarding if the 
called node ID provides this information.) Thirdly, the SETUP message is 
sent to the destination node. Fourthly, a NOTIFY message is sent to the 
1 5 called node with indication of call forwarding and the redirecting and redirec- 
tion name and number. The steps that follow the sending of the NOTIFY 
message will differ depending upon specific factors, e.g., depending upon the 
call forwarding reason, if one is indicated in the forwarding request. Possible 
steps will be described below when referring to Figs. 6A and 6B and 
20 subsequent figures. - > 

Still referring to Fig. 4, since the called node is not in the link 
between the c^afilngpa£ty and the ^f^ ^ded-to^artyT jhe called node is 
released by disconnecting the link between the specified intermediate node 
and the called node. This is shown in Fig. 4 as a step 66 of call clearing 
25 between the called node and the intermediate node. 

If at step 60 no intermediate node has been designated for 
initiating the forwarding path, a determination 68 is made regarding whether 
to use the originating node or the called node to initiate the forwarding path. 
Step 68 may be implemented using the administrable "case event" table 70 of 
30 Fig 5. If the originating node, the called node and the destination node are all 
_ ' " the same lo 9 ical boundary, then Case 1 a p plies. That is. rather t han the _ 
called node initiating the forwarding path, the call is "thrown back" to the 
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originatingjK>de^nd the called node exits from the procedure. This requires 
f ^vardip fl^reciuest message at step 72 of Fig. 4. The request message is 
^sent trornthe called node to the originating node. The called node can then 
be disconnected at step 74, minimizing the number of links involved in 
. 5 connecting the two parties. 

In Case 2, if the called node and the destination node are in the 
same LB, but the originating node is in a different LB, the call is "forward 
switched." That is, the called node is selected at step 68 and the called node 
initiates a forwarding path at step 76. Since the connection between the 
10 calling party and the forwarded-to party includes both the calling path and the 
forwarding path, the called node remains connected. 

In Case 3, the originating node and the called node are in the 
same LB, but the destination node is in a different LB. In this situation, the 
request message is transmitted to the originating node at step 72, the orig- 
15 inating node initiates the forwarding path at step 73, and the called node is 
disconnected at step 74. 

In Case 4, all of the nodes are all in different LBs. The call 
event table indicates that forward switching of the call at step 76 is to be 
provided. However, this is not critical. 
20 Finally, in Case 5, the originating node and the destination node 

are in the same LB, but the called node is in a different LB. Steps 72, 73 and 
74 are followed in order to throw back the call and exit the called node from 
the procedure. 

-Figs. 6A and 6B illustrate the sequence to be followed in an 
25 intermediate node which is set CFMR_R_active. In step 11, a determination 
is made as to whether to invoke rerouting at the intermediate node. If active, 
step 13 is necessary to ensure that the calling party allows this call to be 
forwarded, since if it cannot be forwarded there is no reason to save the 
SETUP message in memory or to monitor the D-channel for a call forwarding 
30 request. 

When steps 1 1 and 13 are "yes" the entire con tents of the 
SETUP message are saved for this call reference at step 15. Then, step 17 
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requires that the backward direction (from the called node) D-channel be 
monitored to detect a forwarding request for call forwarding. If at step 19 a 
CONNect message is received, no forwarding will occur for this call, so the 
memory may be released in step 21 . Monitoring is then stopped and normal 
5 tandem operation of transparent transmitting of messages resumes with step 
23. 

On the other hand, if a forwarding request is detected at step 
25, a determination is made in step 27 as to whether to act on the request. 
This determination at step 27 includes comparing the specified node ID of the 
1 0 node that is to perform the forwarding with the node ID of the intermediate 
node that is executing the steps of Figs. 6A and 6B. If the two node IDs are 
not the same, the memory is released at step 21 , monitoring is stopped and 
normal tandem operation of transmitting messages resumes at step 23. 
When the two node IDs are equal in value, an ACKnowledgement to the 
15 request is sent to the called node in step 29. In step 31 the saved setup 
information is sent to the destination node after being appended with the 
redirecting and redirection numbers and the call forwarding reason, if 
available. The appended information was previously received from the called 
node in the request message. 
20 At step 33, a determination as to what type of forwarding 

occurred impacts what steps occur next. When the call forwarding reason is 
call forward unconditional (i.e.. immediate, busy, all), or when the call 
forwarding reason is unknown, step 35 clears the connection to the called 
node and switches the B-channel connection from the originating node to the 
25 send and receive paths of the destination node. With step 37. a NOTIFY 
message is sent to the originating node to notify it that call forwarding has 
occurred and to identify the redirecting and redirection numbers. After a Call 
PROCeeding message (en-bloc) or SETUP ACK (overlap mode) from the 
destination node is received, step 39 reverts to tandem operations and may 
30 release the saved setup information from memory. 

When step 33 it is determined that the call forwarding reason 
is "delayed call forwarding" (e.g., CF no reply), a NOTIFY message is sent to 
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the originating node to notify it that call forwarding has occurred and to 
identify the redirecting and redirection numbers. This is executed at step 41 . 
The called node and the destination node are alerted simultaneously, but the 
caller at the originating node listens to ringback from the called node. In step 
5 45, the first node to answer is awarded the call. Step 47 makes a 

determination of which is the answering node. When the answering node is 
the destination node, the send and receive paths of the called node are 
switched to the connection to the destination node and the connection to the 
called node is cleared. On the other hand t when the answering party is the 
10 called node, the connection to the destination node is cleared. Both actions 
from step 33 result in execution of step 21, wherein monitoring is stopped and 
normal tandem operation of transparent transmitting of messages resumes 
with step 23. 

Referring now to Fig. 7, greater detail will be described with 

15 respect to selecting an intermediate node, i.e. a tandem/gateway node, as the 
node for initiating a forwarding path. In order for an intermediate node to 
perform rerouting, (1) CFMR_ Reactive must be assigned to the incoming and 
outgoing trunk groups, and (2) the original call setup information must be 
saved at the intermediate node, and (3) a forwarding request message that 

20 includes the node ID of the intermediate node must be received from the 
called node. The request also specifies the name and number of the 
redirecting and destination nodes. In the preferred embodiment, the 
forwarding request message will be transparent to the intermediate node in 
the absence of one of these three requirements. Only the node agreeing to 

25 perform the call forwarding rerouting responds with an ACK message. Since 
saving the original call setup information at the intermediate node requires 
significant switch resources in terms of time and memory, this function 
normally should not be in-service at every intermediate node and for every 
trunk group. The function should be carefully administered. 

30 As an example, if a call originates at a Santa Clara node 78 

within logical boundary 80 and is directed at a Munich node 82 within logical 
boundary 84, the call will tandem through nodes 86, 88, 90 and 92. In this 
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example, it is best to save the original call setup information at Boca node 90 
and at the first Munich node 92, since these two nodes are gateway nodes 
that provide the most efficient rerouting of calls. If the called party, who is a 
subscriber of the second Munich node 82, has identified an address at the 
5 Gent node 94 as the address for forwarding calls, call rerouting is optimized 
by initiating the forwarding path from the Munich gateway 92. The connection 
to the called address of the second Munich node 82 can then be released. 
On the other hand, if the destination address is identified as an address at a 
Minneapolis/St. Paul node 96, the Boca gateway node 90 is likely to be 
10 selected as the node for initiating the forwarding path. Again, the connection 
to the second Munich node 82 is released. Thus, for a call path from Santa 
Clara node 78 to the second Munich node 82, gateway nodes 90 and 92 
should have CFMR_R_active assigned on the outgoing trunk group (i.e., from 
Boca to Munich and from Munich to Boca) and appropriate incoming trunk 
15 groups, as determined by the network administrator. 

The CFMR_R_active/inactive indicator is assigned on a trunk 
group basis. It can be assigned to incoming and outgoing trunk groups. The 
process which checks to determine if a setup message should be saved must 
be aware of whether the relevant node is a tandem/ 
20 gateway node for the particular call. Whether to save the setup message is 
determined by checking the assignment of the CFMR_R_active/inactive. 
However, this check of active/inactive status does not impact the protocol. 

From the perspective of the calling party's node, the call 
forwarding notification has the appearance of an intra-nodaj forward. The 
25 calling party is essentially unaware of the type of rerouting, although this 
information is available in a NOTIFY message. It is possible for a network 
administrator to configure a group of users, or many groups, with a specified 
least cost routing (LCR) authorization to use a particular outgoing trunk group 
at the originating node, with other users at that node being excluded from 
30 access. The network administrator can then administer an associated 

specific intermediate node incoming trunk grou p for CFMR_ R_active in order 

to allow the users having access to be rerouted differently than the others. 
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Figs. 8 and 9 illustrate an example of message flow when call 
forwarding causes rerouting at a gateway node 98. The originating node is a 
PTN/X 100 within a first network 102. The called node 104 is in a second 
network 106. A setup message is transmitted from the originating node to the 
5 gateway node, which passes the setup message to the called node 104. At 
least some of the information of the setup message is saved at the gateway 
node. If call forwarding unconditional (CFU)/call forwarding busy (CFB) is 
invoked, the forwarding management may designate the gateway node 98 as 
the node for initiating the forwarding path to a destination node 108 that is 
10 within the second network 106. 

The called node 104 transmits a first FACILITY message to the 
gateway node 98 to invoke call forwarding. This first FACILITY message is a 
request message. In response, the gateway node (1) sends a second 
FACILITY message to the called node in order to acknowledge reception of 
1 5 the first FACILITY message, and (2) transmits a NOTIFY message to the 
originating node 100. 

The gateway node 98 then executes call forwarding. A setup 
message is transmitted from the gateway node 98 to the destination node 
108. As is well known in the art, ALERTING messages and CONNECT 
20 messages are transmitted from the destination node to the originating node 
via the gateway node. A DISCONNECT is transmitted from the gateway 
node to the called node 104 in order to disconnect the link to the called node. 

Major functional components for providing the message for- 
warding of Figs. 8 and 9 are shown in Fig. 10. The SETUP message from the 
25 originating node 100 is received in memory 110 at the gateway node 98. At 
least some of the setup information will be stored. A tandem operations 
component 112 will pass the setup message to the called node 104. 
FACILITY messages are exchanged between the called node 104 and the 
intermediate rerouting node 98, using the components of operations blocks 
30 113 and 114. 

In the intermediate nod e 98, a receive request co mponent 1 1 5 
receives the call forwarding request and triggers an ACKnowledgement 
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component 116, if the intermediate node agrees to attempt call forwarding. A 
setup-new-path component 117 of the intermediate node then generates the 
SETUP message to a forwarded-to user 119, based upon the stored setup 
information at memory component 110 and from the redirecting and 
5 redirection information received from the FACILITY request from the called 
node 104. The FACILITY request is established and transmitted by the 
throwback-to-intermediate component 123 of the called node, using a control 
table 44 and a case event table 70 of the type previously described with 
reference to Figs. 3 and 5. 

Upon receiving the first backward end-to-end message (such 
messages typically include ALERT and/or CONNect messages, but could 
also be FACILITY, NOTIFY, Progress and Disconnect messages) from the 
destination node 108, the intermediate node 98 clears the connection to the 
called node 104 and transparently transmits messages that are sent and 
received from the originating node 100 and the destination node 108. 

While not shown in Fig. 10. each of the four nodes 98, 100, 104 
and 108 may have all four of the operation blocks 113. 114, 125 and 127 
identified in the figure as CFMR_0, CFMR_R, CFMR_S and CFMR_F com- 
ponents. The CFMR_0 operations block 113 of the originating node 100 
includes a receive request component 129. an ACKnowledge request 
component 131. and a setup-new-path component 133. This operations 
block is the same as the CFMR_R operations block 1 14 in order to support 
throwback-to-the-originating-node signal exchanges with the appropriate 
component 1,35 of the called node 104. Likewise, the setup-new-path 
component 121 in the CFMR_S block is used for forward-switching the call at 
the called node, when the called node is designated by the control and case 
event tables 70 and 44 to be the node for initiating a forwarding path. 

Figs. 1 1 and 12 illustrate an example of message flow in which 
an intermediate node that is not a gateway node is selected for initiating the 
forwarding path. The originating node 120 is in a first network 122. while the 
call ed node 124 is in a second network 126. Communication between the 
two networks is established via a gateway node 128. As shown in Fig. 10, 
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the setup message passes through the gateway node transparently, i.e. the 
gateway node does not store setup information. The gateway node is 

CFMR_R_inactive for the call. 

In addition to the gateway node 128, a tandem node 130 is an 

5 intermediate node along the call path based upon the selection criteria, the 
tandem node 130 is selected for forming the forwarding path 132 to a destina- 
tion node 134. Thus, the appropriate setup information has been stored at 
the tandem node 130. allowing the tandem node to establish a setup 
message for transmission to the destination node 134. The appropriate 

1 0 ALERT and CONNECT messages are exchanged between the destination 
node and the originating node 120. A DISCONNECT message can then be 
sent to the called node 124 to release the called node. 
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Claims 

1 A method of managing forwarding of a call to a destination node (108; 
134), wherein said call to be forwarded is received at a called node (104; 124) 
from an originating node (100; 120) via a call path, said method comprising 
steps of: 

establishing criteria (42 and 70) for selecting among possible 
links between nodes for forwarding calls directed to said called node; 

based upon said criteria, determining (60) whether an 
intermediate node (98; 128) along said call path from said originating node to 
said called node is to be selected for initiating a forwarding path to said 
destination node; 

if said intermediate node is selected for initiating a forwarding 
path, transmitting (62) a request to said intermediate node to initiate said 
forwarding path to said destination node; 

if said intermediate node is unselected, using said criteria to 
select between initiating (64) said forwarding path from said originating node 
and initiating said forwarding path from said called node; and 

(a) transmitting (72) a request to said originating node to 
initiate said forwarding path if said originating node is selected; and 

(b) initiating (76) said forwarding path from said called node 
if said called node is selected. 

2. The method of claim 1 further comprising a step of determining (13; 57) at 
said called node (104; 124) whether said call is allowed to be call forwarded, 
including basing said determination upon setup information received from 
said originating node (100; 120) regarding permissibility of call forwarding 
service. 



3. The method of claim 2 further comprising a step of monitoring (17) a D- 
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channel by said intermediate node (98; 128) when call forwarding rerouting 
has been activated at said intermediate node and said call has been 
determined (13; 57) to be permissible for call forwarding service. 

5 

4. The method of claim 1 1 2 or 3 further comprising a step of disconnecting 
(66) a link from said intermediate node (98; 128) to said called node (104; 
124) when said intermediate node initiates said forwarding path to said 
destination node (108; 134). 

10 

5. The method of claim 1 , 2, 3 or 4 wherein said step of establishing said 
criteria (42 and 70) includes providing a geographical basis for selecting 
among said possible links for forwarding calls, said called node (1 04; 124) ... 

15 being one node in a first group (106; 126) of nodes, said first group being 
linked to other groups (102; 122) of nodes. 

6. The method of claim 5 wherein said steps in which said forwarding path 
20 are selected using said criteria (42 and 70) include determining whether said 

destination node (108; 134) is in the same group of nodes as one of said 
originating node (100; 120) and said called node (104; 124). 

25 7. A system for managing forwarding of a call to a destination node 
comprising: 

memory for storing criteria (44 and 70) for selecting among 
possible links between remote nodes when a call from an originating node 
(100) is to be forwarded from a called node (104) to a destination node (108); 
30 a selector (125), responsive to said stored criteria, for selecting 

among said originating node, said called node and an intermediate node 
(112) along a call path of a call to be forwarded, wherein said selecting 
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designates a node from which a forwarding path to said destination node is to 
be initiated; 

request and response circuitry (123 and 135), operatively 
associated with said selector, for transmitting a request message to at least 
5 one of said originating and intermediate nodes to initiate said forwarding path, 
said request and response circuitry being responsive to said selector when 
said selector designates one of said originating and intermediate nodes; and 

forwarding circuitry (121), responsive to said selector, for 
initiating a forwarding path from said called node to said destination node 
1 0 when said selector designates said called node. 



8. The system of claim 7 wherein said memory, said selector (125), said 
request and response circuitry (123 and 135) and said forwarding circuitry 
15 (121) are interconnected at said called node (104). 



9. The system of claim 7 or 8 wherein said destination node (108) is within a 
first group (106) of related nodes that is connected to a plurality of other 
20 groups (102) of related nodes. 



10. The system of claim 9 wherein said groups (102 and 106) are connected 
by integrated services digital network (ISDN) lines. 

25 
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